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[57] ABSTRACT 

A technique offloads a central directory services (CDS) 
function from a mainframe of an advanced peer-to-peer 
networking (APPN) network to a light-weight directory 
access protocol (LDAP) Accessible Directory Services 
(LADS) residing off the mainframe on another dissimilar 
network. At least one network node of the APPN network is 
configured with LDAP interface that enables communica- 
tion with the LADS. The LADS is configured to provide 
CDS functionality on the dissimilar network, such as a 
Transmission Control Protocol/Internet Protocol network. In 
response to a request from a node on the APPN network, the 
LDAP interface accesses the LADS using the LDAP proto- 
col in accordance with a client-server architecture. 
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TECHNIQUE FOR ACCESSING 
HETEROGENEOUS DIRECTORY SERVICES 
IN AN APPN ENVIRONMENT 

FIELD OF THE INVENTION ' 5 

This invention relates generally to directory services in a 
computer network and, more specifically, to a technique that 
offloads centralized directory services functions from one 
network to another so as to improve the efficiency of 
network bandwidth usage in the one network. 10 

BACKGROUND OF THE INVENTION 

Data communication in a computer network involves the 
exchange of data between two or more entities intercon- JS 
nected by communication links and subnetworks. These 
entities are typically software programs executing on hard- 
ware computer platforms, such as end stations and interme- 
diate stations. Examples of an intermediate station may be a 

router or switch which interconnects the communication „„ 

20 

links and subnetworks to enable transmission of data 
between the end stations. A subnetwork may include a local 
area network (LAN) that provides relatively short distance 
communication among the interconnected stations; in 
contrast, a wide area network (WAN) enables long distance 25 
communication over links provided by public or private 
telecommunications facilities. 

Communication software executing on the end stations 
correlate and manage data communication with other end 
stations. The stations typically communicate by exchanging 30 
discrete packets or frames of data according to predefined 
protocols. In this context, a protocol consists of a set of rules 
defining how the stations interact with each other. In 
addition, network routing software executing on the routers 
allow expansion of communication to other end stations. 35 
Collectively, these hardware and software components com- 
prise a communications network and their interconnections 
are defined by an underlying architecture. 

Modem communications network architectures are typi- 
cally organized as a series of hardware and software levels 40 
or "layers" within each station. These layers interact to 
format data for transfer between, e.g., a source station and a 
destination station communicating over the network. 
Specifically, predetermined services are performed on the 
data as it passes through each layer and the layers commu- 45 
nicate with each other by means of the predefined protocols. 
The lower layers of these architectures are generally stan- 
dardized and are typically implemented in hardware and 
firmware, whereas the higher layers are generally imple- 
mented in the form of software running on the stations 50 
attached to the network. Examples of such communications 
architectures include the Systems Network Architecture 
(SNA) developed by International Business Machines Cor- 
poration and the Internet communications architecture. 

The Internet architecture is represented by four layers 55 
which are termed, in ascending interfacing order, the net- 
work interface, internetwork, transport and application lay- 
ers. These layers arc arranged to form a protocol stack in 
each communicating station of the network. FIG. 1 illus- 
trates a schematic block diagram of prior art Internet pro- 60 
tocol stacks 125 and 175 used to transmit data between a . 
source station 110 and a destination station 150, 
respectively, of a network 100. As can be seen, the stacks 
125 and 175 are physically connected through a communi- 
cations channel 180 at the network interface layers 120 and 65 
160. For ease of description, the protocol stack 125 will be 
described. 
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In general, the lower layers of the communications stack 
provide internetworking services and the upper layers, 
which are the users of these services, collectively provide 
common network application services. The application layer 
112 provides services suitable for the different types of 
applications using the network, while the lower network 
interface layer 120 of the Internet architecture accepts 
industry standards defining a flexible network architecture 
oriented to the implementation of LANs. 

Specifically, the network interface layer 120 comprises 
physical and data link sublayers. The physical layer 126 is 
concerned with the actual transmission of signals across the 
communication channel and defines the types of cabling, 
plugs and connectors used in connection with the channel. 
The data link layer, on the other hand, is responsible for 
transmission of data from one station to another and may be 
further divided into two sublayers: Logical Link Control 
(LLC 122) and Media Access Control (MAC 124). The 
MAC sublayer 124 is primarily concerned with controlling 
access to the transmission medium in an orderly manner and, 
to that end, defines procedures by which the stations must 
abide in order to share the medium. The LLC sublayer 122 
manages communications between devices over a single link 
of the network and provides for environments that need 
connectionless or connection-oriented services at the data 
link layer. 

Connection-oriented services at the data link layer gen- 
erally involve three distinct phases: connection 
establishment, data transfer and connection termination. 
During connection establishment, a single path or 
connection, e.g., an IEEE 802.2 LLC Type 2 or "Data Link 
Control" (DLC) connection as referred hereinafter, is estab- 
lished between the source and destination stations. Once the 
connection has been established, data is transferred sequen- 
tially over the path and, when the DLC connection is no 
longer needed, the path is terminated. The details of such 
connection establishment and termination are well-known. 

The transport layer 114 and the internetwork layer 116 are 
substantially involved in providing predefined sets of ser- 
vices to aid in connecting the source station to the destina- 
tion station when establishing application-to-application 
communication sessions. The primary network layer proto- 
col of the Internet architecture is the Internet protocol (IP) 
contained within the internetwork layer 116. IP is primarily 
a connectionless network protocol that provides internet- 
work routing, fragmentation and reassembly of datagrams 
and that relies on transport protocols for end-to-end reliabil- 
ity. An example of such a transport protocol is the Trans- 
mission Control Protocol (TCP) contained within the trans- 
port layer 114. Notably, TCP provides connection -oriented 
services to the upper layer protocols of the Internet archi- 
tecture. The term TCP/IP is commonly used to refer to the 
Internet architecture. Protocol stacks and the TCP/IP refer- 
ence model are well-known and are, for example, described 
in Computer Networks by Andrew S. Tanenbaum, printed by 
Prentice Hall PTR, Upper Saddle River, N.J., 1996. 

Data transmission over the network 100 therefore consists 
of generating data in, e.g., sending process 104 executing on 
the source station 110, passing that data to the application 
layer 112 and down through the layers of the protocol stack 
125, where the data are sequentially formatted as a frame for 
delivery onto the channel 180 as bits. Those frame bits are 
then transmitted over an established connection of channel 
180 to the protocol stack 175 of the destination station 150 
where they are passed up that stack to a receiving process 
174. Data flow is schematically illustrated by solid arrows. 

Although actual data transmission occurs vertically 
through the stacks, each layer is programmed as though such 
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transmission were horizontal. That is, each layer in the session with a partner LU within a remote end node (such as 

source station 110 is programmed to transmit data to its EN 212). The local EN 202 initially searches its directory 

corresponding layer in the destination station 150, as sche- database for the location of the partner LU. If the location 

matically shown by dotted arrows. To achieve this effect, information is not present in the database, the local EN 

each layer of the protocol stack 125 in the source station 110 5 establishes a CP— CP session with its network node server 

typically adds information (in the form of a header field) to ( sucn ^ NN 2 06) to request a search of the NN's local 

the data frame generated by the sending process as the frame database for the partner LU location. The NN 206 searches 

descends the stack At the destination station 150, the its database for locaJ resources ^ res0 urces within its 

various encapsulated headers are stripped off one-by-one as domain and if the information ^ ntj the route t0 the 

the frame propagates up the layers of the stack 175 until it „ . T 1T . , , , , . , ; r, XT ~ M . 

r r & r j 30 par t ner LU is calculated and conveyed to EN 202 via a 

arrives at the receiving process. , t , , , , , 

OXTA . ' c • » j . , * 4 . t directed locate message exchange through the network 200. 

SNA is a main frame -oriented network architecture that ™ - u . ,f ™ktta • c j j 

, , , . ™ , , . .... Thereafter, a set-up or BIND message is forwarded over 

also uses a layered approach. The services included within . • ™ tTtxtt^ - i j ■ c 

this architecture are generally similar to those defined in the the route lo imUate the ™ n * ™ e f ® IND inclu f 8 info /- 

Internet communications architecture. In a SNA network, matl0n P ert ^ning lo the partner LU requested for the 

though, applications executing on end stations typically 15 session * 

access the network through logical units (LU) of the sta- If the partner LU location is not present in the NN 

tions; accordingly, in a typical SNA network, a communi- database, the NN 206 accesses a central directory server 

cation session connects two LUs in an LU-LU session. (CDS) 250 of the APPN network, if one exists. If the CDS 

Activation and deactivation of such a session is addressed by does not exist, a broadcast search is performed whereby the 

Advanced Peer to Peer Networking (APPN) functions. 20 NN transmits a broadcast locate command that is flooded 

These APPN functions generally include session establish- among all network nodes in the entire APPN network. After 

ment and session routing within an APPN network. forwarding the broadcast locate command onto the other 

FIG. 2 is a schematic block diagram of a prior art APPN NNs, each NN issues a broadcast locate within its own 

network 200 comprising two end stations 202, 212, which domain. 

are typically configured .as end nodes (E^, coupled to token 25 CDS 250 ides centralized registration and search 
ring (TR) networks 204, 214, respectively. Intermediate r r *, ADnK[ 6 . , - nA ~ , 
• ' • . . / j* t n/ functions of all resources in an APPN network 200. To that 
session routing occurs when intermediate stations 206, 216, . _ . 
configured as APPN network nodes (NN), are present in a end ' CDS generally accepts resource registration from and 
session between the two end nodes. The APPN network P r0Vldes directory services to all network nodes in the 
nodes 206, 216 are further interconnected by a WAN 210 30 network. Atypical CDS database implementation resides on 
that extends the APPN architecture throughout the network. a mainframe 260 of the APPN network. Searching opera- 
These intermediate nodes forward frames of an LU-LU tl0ns dieted to the CDS database generally consume 
session over a calculated route between the two APPN end significant resources (e.g., processor cycles) of the main- 
nodes. APPN network and end nodes are well-known and frame wmch ' in turn > hinder execution of "mission critical" 
are, for example, described in detail in Systems Network 35 applications running on the mainframe. Accordingly, users 
Architecture Advanced Peer to Peer Networking Architec- generally prefer issuing broadcast locate operations in lieu 
ture Reference IBM Doc SC30-3422 and APPN Networksby of CDS searches. However, broadcast searches generally 
Jesper Nilausen, printed by John Wiley and Sons, 1994, at consume network bandwidth, thereby adversely impacting 
pgs 11-99 performance of the network. Such broadcast searches should 
Broadly stated, each APPN node includes a control point n be reduced t0 . im P r ° ve n f, twork bandwidth and the present 
(CP) that manages and coordinates APPN related functions "wention is directed to alleviating th.s bandwtdth problem. 

node " M APPN network node is a Mi-functioning SUMMARY OF THE INVENTION 
APPN router node having all APPN base service 

capabilities, including directory services functions. An The invention comprises a technique for offloading a 

APPN end node, on the other hand, is capable of performing 45 central directory services (CDS) function from a mainframe 

only a subset of the functions provided by an APPN network of an advanced peer-to-peer networking (APPN) network 

node. For functions outside is of its capability, the end node having APPN network nodes to a database residing on 

relies on registration in an adjacent APPN network node, another dissimilar network. More specifically, the invention 

which acts as its "network node server". comprises a technique for offloading APPN CDS functions 

For example, directory services in each APPN end node so from a mainframe to a light-weight directory access protocol 

maintain database information on local resources (i.e., LUs (LDAP) Accessible Directory Services (LADS) of the dis- 

in the end node) in addition to information on LUs in similar network while each APPN network node continues 

adjacent nodes with which it may want to establish a session to maintain its local directory services. According to the 

and communicate without involving its network node server. inventive technique, at least one network node of the APPN 

Directory services in a network node maintain a database for 55 network is configured with an LDAP interface that enables 

local resources (LUs in the network node itself) and for communication with the LADS. The LADS, in turn, is 

resources within an area of control (i.e., "domain") of the configured to provide CDS functionality on the dissimilar 

network node. A network nodes's domain includes the network, such as a Transmission Control Protocol/Internet 

network node and all APPN end nodes served by the Protocol (TCP/IP) network. In response to a request from a 

network node. An end node registers its local resources at its 60 node on the APPN network, the LDAP interface accesses the 

network node server via a CP-CP session with the server. In LADS using the LDAP protocol in accordance with a 

addition, the network node maintains a database for client-server architecture. 

resources outside the network node's domain. Directory The invention may be embodied as (i) a proxy CDS 

information is exchanged among all network nodes in an inter face or (ii) a direct access to LDAP interface. According 

APPN environment via CP-CP sessions in those nodes. 6 5 to the proxy CDS embodiment, a designated network node 

During session establishment, an LU within a local end provides access to the LADS on behalf of the entire APPN 

node (such as EN 202) requests an optimum route for a network. Directory services are provided to APPN nodes in 
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a transparent manner, i.e., conventional APPN data flows 
and traffic may be employed to request and receive CDS 
services. The proxy CDS approach may be implemented on 
an existing APPN network to offload CDS processing from 
the mainframe by redirecting CDS requests in the network 5 
to the proxy interface. 

In the direct access to LDAP embodiment, each network 
node is configured with an LDAP interface for accessing the 
LADS on the TCP/IP network. This approach reduces APPN 
locate flows as well as Central Resource Registration (CRR) 10 
flows in an APPN network because these flows are con- 
verted to directly-forwarded requests to the LADS over the 
TCP/IP network. However, each network node must be 
configured and activated for execution of the LDAP proto- 
col. 15 

Advantageously, the invention improves the efficiency of 
bandwidth usage and throughput in the APPN network 
because of the reduction of unnecessary broadcast searches 
in the network. Offloading of CDS services from the APPN 
mainframe improves execution efficiency of "mission criti- 20 
cal" applications by obviating mainframe performance deg- 
radation due to CDS searches. Moreover, the invention 
leverages existing directory services that support the LDAP 
protocol. ^ 

BRIEF DESCRIPTION OF THE DRAWINGS 

The above and further advantages of the invention may be 
better understood by referring to the following description in 
conjunction with the accompanying drawings in which like 30 
reference numbers indicate identical or functionally similar 
elements: 

FIG. 1 is a schematic block diagram of prior art commu- 
nications architecture protocol stacks, such as the Internet 
protocol stack, used to transmit data between stations of a 35 
computer network; 

FIG. 2 is a schematic block diagram of a prior art 
Advanced Peer to Peer Networking (APPN) network includ- 
ing APPN nodes; 

FIG. 3 is a schematic block diagram of a computer 40 
network including an APPN network node modified in 
accordance with a light-weight directory access protocol 
(LDAP) interface to interconnect various subnetworks and 
communication links on which the present invention may 
advantageously operate; 45 

FIG. 4 is a schematic block diagram of the software 
architecture an LDAPmodified APPN network node accord- 
ing to the invention; 

FIG. 5 is a schematic block diagram of protocol stacks 50 
contained within LDAPmodified APPN network node of the 
present invention; and 

FIG. 6 is a schematic diagram of the structure of a central 
directory service database coupled to an LDAP server 
which, collectively, are organized as an LDAP Accessible 55 
Directory Services according to the present invention. 

DETAILED DESCRIPTION OF AN 
ILLUSTRATIVE EMBODIMENT 

FIG. 3 is a schematic block diagram of a computer 60 
network 300 comprising a collection of interconnected com- 
munication links and subnetworks attached to a plurality of 
stations. The stations are typically computers comprising 
end stations 302, 312 and intermediate stations 400^6. 
Preferably, the end stations are Advanced Peer to Peer 65 
Networking (APPN) end nodes, although the stations may 
comprise other types of nodes such as Low Entry Network- 
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ing nodes or Physical Units 2.0 via Dependent Logical Unit 
Requestor functions. In addition, the intermediate stations 
400a f b (generally designated 400) are preferably APPN 
network nodes modified in accordance with a light-weight 
directory access protocol (LDAP) interface according to the 
present invention. 

Each node typically comprises a plurality of intercon- 
nected elements, such as a processor, a memory and a 
network adapter. The memory may comprise storage loca- 
tions addressable by the processor and adapter for storing 
software programs and data structures associated with the 
inventive technique. The processor may comprise process- 
ing elements or logic for executing the software programs 
and manipulating the data structures. An operating system, 
portions of which are typically resident in memory and 
executed by the processor, functionally organizes the node 
by, inter a/ia, invoking network operations in support of 
software processes executing on the node. It will be apparent 
to those skilled in the art that other processor and memory 
means, including various computer readable media, may be 
used for storing and executing program instructions pertain- 
ing to the technique described herein. 

The subnetworks included within network 300 are pref- 
erably local area networks (LANs) and the communication 
links may include wide area network (WAN) links; in the 
illustrative embodiment of the invention, the LANs are 
token rings (TR) 304, 314 and a Transmission Control 
Protocol/Internet Protocol (TCP/IP) network 310, which 
may comprise either a LAN and/or a WAN configuration 
such as X.25, interconnects the nodes 400, As described 
further herein, an LDAP server 350 having a database 600 
is coupled to the TCP/IP network 310. Communication 
among the nodes coupled to the network 300 is typically 
effected by exchanging discrete data packets or frames via 
connection-oriented service sessions between the commu- 
nicating nodes. 

FIG. 4 is a schematic block diagram of the software 
architecture of an APPN network node 400 modified to 
operate with an LDAP interfacing technique of the present 
invention. Application 402 communicates with another node 
through an LU-LU session; LU 404 within the node func- 
tions as both a logical port for the application to the network 
and as an end point of the communication session. The 
session generally passes through a path control module 412 
and a data link control (DLC) module 416 of the node, the 
latter of which connects to various network transmission 
media. 

When functioning as an APPN router node, an interme- 
diate session routing (ISR) module 405 maintains a portion 
of the session in each "direction" with respect to an adjacent 
network node of network 300. In response to receiving the 
BIND message during session establishment, path control 
412 and ISR 405 are invoked to allocate resources for the 
session. In particular, each router node allocates a local form 
session identifier for each direction of the session. 
Collectively, each of these individually-established "local" 
sessions form the logical communication session between 
LUs of, e.g., the end nodes 302, 312. 

During session establishment, an end node (such as EN 
302) establishes a CP — CP session with a control point (CP) 
module 408 of the APPN network node 400 to request a 
search to acquire location information for a partner LU. The 
CP 408 coordinates performance of all APPN functions 
within the node, including maintenance of a directory ser- 
vices database 410. The CP searches its database for local 
resources and resources within its domain and, if the infor- 
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mation is present, the route to the partner LU is calculated 
and conveyed to EN 302 via a directed locate message 
exchange through the network 200. Thereafter, the BIND 
message is forwarded over the route to initiate the session. 

If the partner LU location is not present in the database 5 
410, the APPN network node 400 either accesses a central 
directory server (CDS) of the APPN network to request the 
location information or issues a broadcast search among all 
network nodes in the network. A typical implementation of 
CDS resides in a virtual telecommunications access method 10 
(VTAM) on a mainframe of the APPN network. VTAM is 
software system that manages a network, such as an SNA or 
APPN network. Searching of the CDS database consumes 
significant resources of the mainframe that may be otherwise 
used for executing VTAM -related or "mission critical" 35 
applications, whereas broadcast searches consume valuable 
network bandwidth. In either case, there is an adverse 
impact on the performance of the APPN network resources. 
The invention provides a technique for offloading the CDS 
function from the mainframe of the APPN network to a 20 
database residing on another dissimilar network. 

According to the inventive technique, APPN network 
node 400 is configured with an LDAP interface 450 that 
enables communication with the LDAP server 350. The 
LDAP interface 450 is preferably implemented as an appli- 25 
cations programming interface (API) layer coupled to appli- 
cation layer 402 of the node 400. In response to a request 
from a node on the APPN network, the LDAP interface 450 
accesses the database 600 of the LDAP server 350 using a 
conventional LDAP protocol over the TCP/IP network in 30 
accordance with a client-server architecture. 

FIG. 5 is a schematic block diagram of a protocol stack 
500 within the APPN network node 400. Applications 
executing on SNA devices (end stations) 302, 312 typically 3S 
access the network through logical units (LUs) of the 
stations and communicate via LU — LU sessions. Network 
node 400 functions to facilitate establishment and routing of 
these connection-oriented communication sessions within 
the network. To accomodate such routing establishment 4Q 
operations, protocol stack 500 preferably comprises an 
APPN layer 502 that contains the software . modules 
described in FIG. 4. 

The stack 500 also includes a Transmission Control 
Protocol/Internet protocol (TCP/IP) layer 504 containing 45 
those layers of the Internet communications architecture 
protocol stack (FIG. 1) needed to establish, e.g., conven- 
tional connection-oriented, TCP communication sessions. 
Data link control (DLC) layers 512 and 514 provide a 
connection-orented service via conventional DLC 50 
connections, while physical sublayers 522 and 524 specify 
the electrical, mechanical, procedural and functional speci- 
fications for activating, maintaining and de-activating the 
physical links 530 and 550 of the network. The establish- 
ment of TCP sessions is described in Internetworking with 55 
TCP/IP by Comer and Stevens, printed by Prentice Hall, 
1991, which publication is hereby incorporated by reference 
as though fully set forth herein. 

FIG. 6 is a schematic diagram of the structure of the 
database 600 which is generally configured similar to a 60 
traditional CDS database of an APPN network. That is, the 
information stored on the CDS database is similar to the 
information provided by APPN nodes when registering their 
resources on a CDS database and, to that end, generally 
pertains to the resource name and its hierarchical association 65 
in the APPN network. According, the database 600 com- 
prises a plurality of information units, schematically shown 
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at 610, each of which includes a plurality of fields. For 
example, a field 612 contains the name of an LU resource 
(LU name) and a field 614 contains the name of an associ- 
ated control point of its network node server (CP name). The 
CP name is preferably symbolically represented as CP 
name=NETID.PU name, wherein NETID is a network iden- 
tifier and PU name is the name of a physical unit (PU) 
resource. 

In the illustrative embodiment described herein, the 
LDAP server 350 (in connection with the CDS database 
600) is preferably organized as a conventional X.500 direc- 
tory service, hereinafter referred to as LDAP Accessible 
Directory Services (LADS). A requirement of the invention 
is that the server 350 operate according to the LDAP 
protocol that is typically used in OSI environments over 
X.500 directory services networks. Broadly stated, the 
LDAP protocol enables peer nodes to communicate in a 
client-server arrangement to access a directory service over 
the TCP/IP network. The LDAP protocol is well-known and 
described in detail in Request for Comment (RFC) 1777 by 
Yeong, Howes & Kille, 1995 at pgs 1-38, which is hereby 
incorporated by reference" as though fully set forth herein. 

In accordance with the invention, the LDAP interfacing 
technique may be embodied as (i) a proxy CDS interface or 
(ii) a direct access to LDAP interface. According to the 
proxy CDS embodiment, all requests for directory services 
from nodes of the APPN nework are directed to a designated 
network node (such as network node 400) rather than to the 
CDS in VTAM, In other words, the designated network node 
400 is advertised throughout the APPN network as a CDS 
such that all CDS requests issued by network nodes of the 
APPN network "funnel" to the node 400. The proxy CDS 
node 400 then provides access to the LADS on behalf of the 
entire APPN network through its LDAP interface. 

Directory services arc provided to APPN nodes in a 
transparent manner, i.e., conventional APPN data flows and 
traffic may be employed to request and receive CDS ser- 
vices. The proxy CDS approach may be implemented on an 
existing APPN network to offload CDS processing from the 
mainframe by redirecting CDS requests in the network to the 
proxy interface. An advantage of this embodiment is that just 
one network node need be configured with the proxy CDS 
feature; this reduces the overall impact on an existing APPN 
network. 

In the direct access to LDAP embodiment, each network 
node of the APPN network is configured with an LDAP 
interface 450 for directly accessing the database of LDAP 
server 350 over the TCP/IP network. This approach reduces 
APPN locate flows as well as Central Resource Registration 
(CRR) flows over the APPN network because these flows 
are converted to directly-forwarded requests to the LADS 
over the TCP/IP network. However, each network node must 
be configured and activated for execution of the LDAP 
protocol. 

Advantageously, the invention improves the efficiency of 
bandwidth usage and throughput in the APPN network 
because of the reduction of unnecessary broadcast searches 
in the network. Offloading of CDS services from the APPN 
mainframe improves execution efficiency of "mission criti- 
cal" applications by obviating mainframe performance deg- 
radation due to CDS searches. Moreover, the invention 
leverages existing directory services that support the LDAP 
protocol. 

While there has been shown and described an illustrative 
embodiment for offloading a CDS function from a main- 
frame of an APPN network to a database residing off the 



03/29/2004, EAST Version: 1.4.1 



6,154, 

9 

mainframe on another dissimilar network, it is to be under- 
stood that various other adaptations and modifications may 
be made within the spirit and scope of the. invention. For 
example in an alternate embodiment of the invention, the 
LDAP server 350 (in connection with the CDS database) 5 
may be configured in accordance with other directory ser- 
vice organizations, such as NetWare Directory Services 
from Novell, Inc. As noted, a requirement of any embodi- 
ment of the server 350 is that it operate according to the 
LDAP protocol described in detail in Request for Comment 
(RFC) Mil by Yeong, Howes & Kille. 10 

The foregoing description has been directed to specific 
embodiments of this invention. It will be apparent, however, 
that other variations and modifications may be made to the 
described embodiments, with the attainment of some or all 
of their advantages. Therefore, it is the object of the 15 
appended claims to cover all such variations and modifica- 
tions as come within the true spirit and scope of the . 
invention. 

What is claimed is: 

1. A method for offloading a central directory services 2 q 
(CDS) function from a mainframe of an advanced peer-to- 
peer networking (APPN) network to a database residing on 

a dissimilar network, the method comprising the steps of: 
modifying at least one network node of the APPN net- 
work with a light-weight directory access protocol 
(LDAP) interface; 25 
organizing the database to provide CDS functionality on 

the dissimilar network; and 
in response to a request from another node of the APPN 
network, accessing the CDS database in accordance 
with an LDAP protocol to enable communication 30 
between the LDAP interface and CDS database. 

2. The method of claim 1 wherein the dissimilar network 
is a Transmission Control Protocol/Internet Protocol (TCP/ 
IP) network. 

3. The method of claim 2 wherein the step of modifying 35 
further comprises the step of configuring the LDAP interface 

as one of a proxy CDS interface and a direct access LDAP 
interface, 

4. The method of claim 3 wherein the step of configuring 
the LDAP interface comprises the step of designating the at 4Q 
least one network node as a proxy CDS interface that 
provides access to the CDS database on behalf of all nodes 

of the APPN network. 

5. The method of claim 3 wherein the step of configuring 
the LDAP interface comprises the step of configuring each 
network node of the APPN network with an LDAP interface 45 
such that each network node has direct access to the CDS 
database. 

6. The method of claim 1 wherein the CDS database is a 
LDAP Accessible Directory Services. 

7. A system configured to offload a central directory 50 
services (CDS) function from a mainframe of an advanced 
peer-to-peer networking (APPN) network to a database 
residing off the mainframe on a dissimilar network, the 
system comprising: 

' at least one network node of the APPN network coupled 55 
to the dissimilar network and configured with a light- 
weight directory access protocol (LDAP) interface; 

a database with CDS functionality coupled to the dissimi- 
lar network, the CDS database organized as an LDAP 
Accessible Directory Services (LADS); and 60 

means, coupled to the at least one network node, for 
accessing the LADS in accordance with an LDAP 
protocol to enable communication between the LDAP 
interface and LADS. 

8. The system of claim 7 wherein the dissimilar network 65 
is a Transmission Control Protocol/Internet Protocol (TCP/ 
IP) network. 
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9. The system of claim 8 wherein the LDAP interface is 
configured as one of a proxy CDS interface and a direct 
access LDAP interface. 

10. The system of claim 9 wherein the proxy CDS 
interface comprises a designated network node that provides 
access to the LADS on behalf of all nodes of the APPN 
network. 

11. The system of claim 9 wherein the direct access LDAP 
interface comprises each network node of the APPN net- 
work configured with an LDAP interface to enable each 
network node to directly access to the LADS. 

12. A method of offloading a central directory services 
(CDS) function within a mainframe of an advanced peer- 
to-peer networking (APPN) network to a dissimilar network, 
the method comprising the steps of: 

offloading the CDS to the dissimilar network; 

modifying at least one node to access the CDS at the 
dissimilar network; 

tunneling a CDS request from another node to the modi- 
fied node; and 

accessing of the CDS by the modified node on behalf of 
the requesting node. 

13. The method of claim 12, wherein the CDS offloading 
step comprises of: 

offloading the CDS functions from a mainframe to a 
light-weight directory access protocol (LDAP) acces- 
sible directory services (LADS) of the dissimilar net- 
work. 

14. The method of claim 13, wherein the node modifying 
step comprises of: 

configuring the node with a light-weight directory access 
protocol (LDAP) interface that enables communication 
with the LADS. 

15. The method of claim 12, wherein the dissimilar 
network is a Transmission Control Protocol/Internet Proto- 
col (TCP/IP) network. 

16. The method of claim 14 wherein the node modifying 
step further comprises the step of: 

configuring the LDAP interface as one of a proxy CDS 
interface and a direct access LDAP interface. 

17. A system configured to offload a central directory 
services (CDS) function from a mainframe of an advanced 
peer-to-peer networking (APPN) network to a dissimilar 
network, the system comprising: 

the CDS functions coupled to the dissimilar network; 

at least one network node of the APPN network coupled 
to the dissimilar network and having access to the CDS; 

a CDS request node coupled to the CDS access node to 
funnel a request, wherein the CDS access node accesses 
the CDS on behalf of the CDS request node. 

18. The system of claim 17, wherein the CDS functions 
are included in a light-weight directory access protocol 
(LDAP) accessible directory services (LADS) of the dis- 
similar network. 

19. The method of claim 18, wherein the CDS access node 
is configured with a light-weight directory access protocol 
(LDAP) interface that enables communication with the 
LADS. 

20. The system of claim 17 wherein the dissimilar net- 
work is a Transmission Control Protocol/Internet Protocol 
(TCP/IP) network. 

21. The system of claim 19 wherein the LDAP interface 
is configured as one of a proxy CDS interface and a direct 
access LDAP interface. 

***** 
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